In recent years, along with the spread of businesses using the Web (World Wide Web) technologies, some applications have been developed in the form in which a plurality of Web sites provide cooperative services. For example, there is a scenario in which a user moves from a Web site of an insurance company to a site of a bank where the user receives a loan on security of one's insurance to make a payment, and then returns to the Web site of the insurance company again to continue the operation.
In a great number of application scenarios, when the user moves from site A to site B and then returns to site A (assumed A′), it is necessary that the session information be inherited from A to A′. Usually, the session information is stored in a memory or database on the server side, and a server application can access the session information for each user with the session ID transmitted from the browser as a key. The session ID is transmitted from the server to the browser in establishing a first session, and held as a cookie on the browser side.
However, in a Web application system constructed in combination with a load balancing server and an authentication server for a Single-Sign On (enabling all the permissible functions for a server or directory having the access right by making the user authentication once), there are some cases where the above session inheriting scheme may not operate.
FIG. 6 is a diagram showing an exemplary configuration in which this problem may possibly occur. In an example of FIG. 6, a self-company site (site A) 201, the other company site (site B) 211, and a browser 221 are connected via the Internet 231. In this self company site 201, an authentication server 202 of reverse proxy type (controlling all the accesses via a proxy server for security purposes) and a load balancing server 203 are combined, in which a first Web application server 204 and a second Web application server 205 are shown as the application servers allocated to the load balancing server 203. It is assumed here that the authentication server 202 that accepts a request through the Internet 231 has an IP address of 9.100.1.1, and the first Web application server 204 and the second Web application server 205 that perform the actual processes have the IP addresses 192.168.0.1 and 192.168.0.2, respectively. The load balancing server 203 dispatches any one of three cluster addresses (virtual addresses accepted by the load balancing server 203) 192.168.1.0, 192.168.1.1 and 192.168.1.2 in accordance with the predetermined rules.
FIG. 7 is a table for listing rules of dispatching each cluster address. Herein, the virtual cluster address 192.168.1.0 is dispatched to real address 192.168.0.1 and 192.168.0.2 uniformly for every HTTP request as a rule. Also, the virtual cluster address 192.168.1.1 is dispatched to 192.168.0.1 as a rule, or to 192.168.0.2 when it is determined that the real address 192.168.0.1 is down. Moreover, the virtual cluster address 192.168.1.2 is dispatched to 192.168.0.2 as a rule, or to 192.168.0.1 when it is determined that the real address 192.168.0.2 is down.
The address 9.100.1.1 of authentication server 202 is a public IP address. By pre-negotiation, or any desirable means, browser 211 also knows the URLs 9.100.1.1/cluster0, 9.100.1.1/cluster1 and 9.100.1.1/cluster2. These URLs are translated to site A's internal IP addresses 192.168.1.0, 192.168.1.1 and 192.168.1.2, respectively by the authentication server (reverse-proxy). And then requests to these internal addresses are all handled by the load balancer and dispatched to the back-end Web servers 192.168.0.1 or 192.168.0.2 as dispatching rules of each internal address. The URL 9.100.1.1/cluster0 is used for initial load-balancing, and requests to that URL are dispatched to Web servers 192.168.0.1 or 192.168.0.2 as load balancing suggests. The URLs 9.100.1.1/cluster1 and 9.100.1.1/cluster2 are used to fix the target Web server to maintain “sticky” sessions, and they directly access Web server 192.168.0.1 and 192.168.0.2, respectively (except when the target server is down).
The URLs 9.100.1.1/cluster1 and 9.100.1.1/cluster2 are returned to the client in the form of an embedded URL link by the Web server that handled the client's first request and established the session. Whether a client uses cluster1 or cluster2 depends on which Web server handled the client's first request.
A first request to a Web application server is transmitted from authentication server 202 via the cluster address 192.168.1.0, and dispatched to the real address 192.168.0.1 or 192.168.0.2 by load balancer 203. With a function of an HTTP server on the Web application server side, the request dispatched to the real address 192.168.0.1 is redirected to the cluster address 192.168.1.1 and the request dispatched to the real address 192.168.0.2 is redirected to the cluster address 192.168.1.2 (the response is once returned to the browser side and the request is automatically transmitted to the server side again). The “redirect” means that a HTTP server returns a response containing a Location response-header (defined in HTTP specification RFC2068) to a client, and the client automatically transmits a request according to the description of the Location response-header.
The authentication server 202 accepts the requests which from a client at the three cluster addresses by making a conversion as shown in FIG. 8. This conversion is totally performed for the request URL from the browser 221 and the URL described in the HTML of the response. For example, in a case where there is a description of “/index.html” in an anchor tag in the response HTML, the cluster address might be converted into “/cluster1/index.html” and delivered to the browser 221. By performing this processing, an HTTP request from a certain user is dispatched into either the first Web application server 204 or the second Web application server 205 at a uniform probability at first. Since then, it is assured that the request from that user is dispatched (offset) to the same server, whereby the session information can be inherited while making load balancing. There is a method of identifying the user and dispatching or offsetting, using the IP address on the browser side, but this method is not effective in the case where a proxy like the authentication server 202 is placed at the front end with the configuration as shown in FIG. 6. In these cases, the source IP address of all incoming packets is the address of the proxy, not the original client. The load balancing server 203 regards all the requests as arriving directly from the authentication server 202, the user can not be distinguished.
Under the above environment, it is supposed that the user is piloted from site A of the self company site 201 to site B of the other company site 211 and back to site A′ of the self company site 201 again. To pilot the user from site B to site A′, it is necessary that the URL information for linking to site A′ is described in the response HTML file from site B. It is common practice that the stationary URL (9.100.1.1/cluster0) of site A is informed in advance to site B 211 in cooperative relation to have it embedded in the HTML.
However, when the offset (the “offset” means that the request addresses from a client are fixed to either of 9.100.1.1/cluster1 or 9.100.1.1/cluster2, once after the first request is sent to 9.100.1.1/cluster0) is firstly made at site A, a cookie is created in connection with the Path information “/cluster1” or “/cluster2” and sent to the browser 221 in a response, and as for the requests to the URL with the Path information unmatched (a cookie created at a request to 9.100.1.1/cluster1□□is not sent to the server when a client send a request to 9.100.1.1/cluster2), the session ID is not sent to the server side (self company site 201) for security reasons. The “security reasons” is to avoid sending a cookie carelessly. Supposing that the user interacts with site A using an address 9.100.1.1/cluster1 and then makes a request to site A′ at 9.100.1.1/cluster0 after moving to site B, the server application can not access the previous session information, even if this request is sent to the same Web application server as processed at site A. This is because the browser 221 determines that 9.100.1.1/cluster0 and 9.100.1.1/cluster1 are different transmission destinations, and does not transmit the cookie (session ID) employed in transactions with 9.100.1.1/cluster1 to the server side.
This problem occurs in combination of:                Authentication server method and security policy to be set up there        Load balancing method and configuration        Application scenario transferring from self site to other site to self site.        
Though there is a technical configuration of authentication or load balancing in which this problem does not occur, the authentication or load balancing method is constrained by many other conditions (security policy of the entire company, performance request, specifications of other company products) before examining the adaptability with the individual application scenarios. There is a method of inheriting the file or data stored in the database on the Web application server side with the user ID as a key, but the individual packaging is required for each application.
The present invention has been achieved to solve the above-mentioned technical problems, and it is an object of the invention to provide a systematic method of solving a problem of inheriting the session information on the application server side when there are other sites interposed.